fix(coordination): revalidate canonical claims after CAS contention - #5371
Conversation
Signed-off-by: lusendong.6789 <lusendong.6789@bytedance.com> Co-authored-by: TRAE CLI <traecli@bytedance.com>
Signed-off-by: lusendong.6789 <lusendong.6789@bytedance.com> Co-authored-by: TRAE CLI <traecli@bytedance.com>
|
Self-review of head
|
huangruiteng
left a comment
There was a problem hiding this comment.
Exact-head review: #5371
Reviewed head: a38d31c62a74fbc031a4e2957397f8eaddfd3102; immutable base: 04bf6b6c1c1d37d3b19194c91efe5b4c4d9daa7d.
没有发现阻塞问题。这次批准针对 canonical claim 的有界 CAS 恢复,不代表多主机持续吞吐、provider promotion 或合并授权。
动机
两个 Agent 认领不同 Todo 时,底层共享 revision 仍可能竞争。旧路径把这类内部 CAS 拒绝直接交给调用方,导致独立工作需要再次介入;更危险的修法则是重放旧 projection,覆盖先成功的认领。现有 shared-authority RFC 的 contention 契约要求:独立目标可以基于最新权威完成,同目标或写范围冲突仍必须拒绝。这是可独立交付的 correctness 增量,不是靠测试数量宣称全局迁移完成。
改动思路
重试放在既有 TypeScript claim owner,而非 CLI/Python/provider 各自实现。只有明确的 conflict + provider_revision_mismatch 会重新执行完整 attempt;最多增加两次尝试。每次先查同 operation 的回执,再读完整 canonical head,重做 actor/claim、Todo lifecycle、acceptance、lease 和 scope 判断。显式 revision 与 transfer grant 保持固定观察,不自动升级授权;写入结果不明确则继续由既有 receipt recovery 处理,不能当作 CAS 拒绝重试。
普通 CLI 已调用该 owner,continuation 的 revision/grant 绑定路径也保留原有边界。没有新增配置、状态表、schema、账号权限、前端/Lark 动作或调用者确认步骤。代码复用审查覆盖了 local adapter、continuation、command receipt 与 lease proof;没有增加第二个 Python 决策源。
具体改动
唯一生产改动是 todo_claim.ts 的 17 行 wrapper/私有 attempt 分离。新 claim_contention_conformance.ts 在既有真实 provider factory 上执行七类竞争;authority_store_conformance.ts 注册该组,将同 Todo 竞争和 lease 被替换后的旧 conflict 断言更新为重新校验后的具体拒绝,并保留 lost-response 的 recovered/回执检查。两份 TS migration RFC 同步披露默认行为变化及“不证明持续吞吐”的边界。五个文件全部纳入审查,没有只复核新增 happy path。
关键代码讲解
executeCoordinationTodoClaim:输入还是相同 claim intent、operation 和 lease key。attempt >= 2、显式 revision、transfer grant、非 conflict 或非 revision mismatch 都立即返回;不会把 lease 冲突、无权限或 ambiguous write 包装成可重试错误。executeClaimAttempt:原有校验和事务主体不变。新 attempt 从回执和完整权威开始,不复用上次 prepared projection;receipt、source witness、eligibility、acceptance、lease 排他仍由原 owner 决策。成功/replay 的当前 lease proof 也仍由原 proof owner 生成。claimLocalCoordinationTodo:实际 CLI 的 TS adapter,在 canonical writer 边界调用共同 claim owner,并返回真实 provider/readback 来源;没有新增 legacy fallback。它未被修改,但证明 wrapper 是可达生产路径,而非孤立 helper。registerClaimContentionConformance:独立目标应有两个 durable winner;同目标/重叠 scope 只有一个 winner,失败方不能留下成功回执。另检查新 acceptance、固定 revision、source change 和三次耗尽;这些是状态不变量,不只是返回字段快照。
正向与失败路径
我另外用同一独立探针对 immutable base/head 做十个完整观察:通过公共 local claim entrypoint 接真实 File store,在首次 commit 前让另一真实 writer 产生 CAS 竞争;只有 pinned case 直接调用公开 typed owner,因为 local adapter 不暴露该字段。独立 Todo 在 base 返回 conflict,head 重新读取后 applied;两位 owner、两个 lease、100 个无关完整 Todo 和 projection 附加数据都保留。成功后同 operation replay 不新增效果、不改原回执或最终状态。
同 Todo、重叠 scope、竞争后已完成/已归档目标,head 分别返回 claim_owner_mismatch、write_scope_conflict、todo_not_open、todo_archived,失败方回执缺失。持续竞争恰好尝试三次后返回 conflict;显式 revision 仍只尝试一次。普通成功、dry-run、错误 actor、pinned revision 四个对照的完整观察一致。仅归一化 File 随机 store identity 派生的 revision 摘要,保留版本并检查同观察内引用绑定;没有删掉状态、错误、lease、receipt 或 effect 差异。
验证不是由替换实现生成 expected:两个独立目标不能丢失彼此、冲突方不能获得 authority、固定观察不能悄悄更新等 oracle 来自既有共享权威契约。让同一 head oracle 跑 base 会在 independent case 失败,说明不是“新旧都能绿”的空探针。初版探针的非协议 fixture 字段、dry-run 预期和 archive literal 有错误,已按既有 schema 修正;这些构造失败未算作 PR 失败或通过证据。
对主干的风险
主要风险是把 ambiguous commit 当成确定失败后重写,或重试时遗漏新的 ownership/acceptance/scope 限制。wrapper 的精确 typed status 判断、完整 attempt 重执行及既有 receipt recovery 将两者隔开。重试无 backoff,但上限仅三次,不能无限消耗或扩大 fixed grant;高争用仍返回明确 conflict,由调用者重新观察。100 个无关记录及后续 replay/readback 检查覆盖了 accumulated-state 与重复效果风险,没有用截断 display 当权威来源。
我在该 exact head 实际执行:
- File + SQLite 原生 authority suites:648 passed,0 failed/0 skipped。
- 隔离真实 PostgreSQL 16.15:
npm run test:postgresql-authority-store,315 passed,0 failed/0 skipped;仅合成夹具,临时实例已停止。 - 实际 Python→TS CLI claim/transfer/proof tests:7 passed,覆盖 File/SQLite、replay、projection recovery、lease lifecycle 与 transfer。
npm run typecheck:control-plane、全树 semantic-vocabulary smoke、control-plane maintainability ratchet、changed-diff advisory、whitespace 与五个候选文件 public-boundary scan:通过。advisory 无支持语法中的新 vocabulary 定义,不将它视为语义等价证明。
没有查询或等待远端 CI;没有验证 live NoKV、部署晋升或跨主机持续负载。没有修改 UI/配置入口,其 adapter/request/readback 契约未变,故不需要为本修复新增 companion UI。长期任务结果是减少内部 revision 竞争造成的重复操作,同时保留恢复、拒绝和幂等边界;用户无需重新填写已知 intent 或增加批准步骤。
我的整体评价
APPROVE。这是现有 TS authority owner 的小而完整修复,生产增量与故障范围相称。未来重构检查已落实为 wrapper/单次 attempt 分离,复用旧 receipt/lease/source owner;不建议扩成通用 retry framework,也不因大型文件存在就扩大迁移。剩余多主机吞吐和 provider 准入仍由现有 shared-authority / TS migration acceptance 负责。本批准不关闭那些验收,也不授权合并。发布后应按 review capability 执行旧阻塞评审核对;只有逐条证实已解决且具备权限,才可原生撤销,不能凭本批准清除异议。
English verdict: APPROVE - a38d31c62a74fbc031a4e2957397f8eaddfd3102: bounded conclusive-CAS retries revalidate canonical authority and preserve pinned/ambiguous recovery. Verified 648 File/SQLite tests, 315 real PostgreSQL tests, 7 CLI tests and ten independent immutable base/head observations. No sustained-throughput or merge authorization claim.
|
This pull request has merge conflicts with Choose the remote for the base repository, not an out-of-date fork. git fetch upstream
git rebase upstream/main
# Resolve each conflict, git add the resolved files, then git rebase --continue.
git push --force-with-lease origin HEADFor a same-repository clone whose Keep the DCO |
Signed-off-by: huangruiteng <huangrt01@163.com>
huangruiteng
left a comment
There was a problem hiding this comment.
Reviewed exact head 7ddeddb481924621265a424bb7f0fa02ad525f2f, against immutable main 850268bffc6f7123e88f578d3743f8f6da5c5c73.
未发现这份 PR 的阻塞缺陷。独立认领的争抢修复已经过真实 provider 和原有 CLI 路径验证;本地 premerge 有单独的主干/环境阻塞,不能宣称全绿或已可合并。
动机
两个独立 Todo 从同一 canonical head 发起认领,原来其中一个即使仍有合法 owner 和不重叠的写范围,也只能收到 CAS 冲突,再让调用方重跑。七个相同的真实 File 场景在 immutable main 上有五个预期回归失败、两个保留行为通过;本 head 七个全部通过。这修复 canonical writer 的有界行为,不代表完整 App 协作、持续多主机吞吐或推荐项预留已验收。
改动思路
复用既有 TS claim owner,提取完整的私有 attempt,再用至多两次重试处理明确的 provider_revision_mismatch。每次读取同一个 operation 的回执和完整权威,重验来源、owner、acceptance 和 lease/write scopes。doing nothing 保留无谓的重跑;在通用 receipt helper 或 Python caller 加重试会形成错误的权限/结果不明确边界,所以当前 17 行生产改动归属合理。
具体改动
executeCoordinationTodoClaim包装原有完整executeClaimAttempt;显式 revision、transfer grant、非 CAS 冲突、语义拒绝和结果不明确的写入保持原监督路径。local_authority_runtime.ts与todo_continuation.ts继续调用同一个 command,不增加新入口或持久化字段。claim_contention_conformance.ts以真实存储 CAS 和调度 barrier 检验独立/同 Todo/写范围碰撞、新 acceptance、source、pinned revision 和耗尽。独立场景读回两个 winner 的 owner/lease,重复 operation 的原回执保持不变;失败方无认领回执。barrier 只改变时序,不伪造成功、回执或 postcondition。authority_store_conformance.ts注册七个共用场景,并将旧的 bare-conflict 断言改名为当前语义拒绝断言;原有 owner、lease、响应丢失/回执恢复不变量仍在。- 中英文 TS migration RFC 说明改变的默认行为和适用 caller。本次合入 main 只修复两处 RFC 文本冲突,同时保留 claim-contention 与 scoped gate-action 的检查点;原生产实现相对前一次 head 没改。
对主干的风险
最高风险是重试把已变更的 owner、acceptance 或写范围当成旧观察,或把不明确成功重新写一遍。完整 attempt、原 operation/lease key 和精确 conflict predicate 阻止这些路径;相同目标/重叠范围只保留一个 owner,新 acceptance 拒绝无回执,pinned intent 不重试,第三次冲突停止,既有丢响应恢复保持一个 commit。没有字符串启发式、平行 Python 决策 owner、新 authority 名称、feature gate 或自动加载指令。相关 conformance 和真实 CLI 测试覆盖持久化读回、replay、retirement、transfer;UI/Lark 的配置和动作契约没有变化,无需额外用户步骤。
本 head 的完整 File 326、SQLite 338、隔离真实 PostgreSQL 16.15 322 个测试全部通过、零跳过;七个源 CLI claim/proof/transfer 测试通过,TS typecheck、语义 inventory、maintainability、diff 和公共边界检查通过。PostgreSQL 使用一次性合成租户,结束后已停机。精确五文件 quality receipt cqr_beabc7329dba57135c17 有效。
风险选择的 premerge 执行了 18 项:九项通过,九项失败。对 immutable main 执行同样九条失败命令,复现相同的 default-runtime routing collision:八个相同 ValueError,以及 catalog-planner 嵌套 facade 的同一失败断言。此次 diff 不修改其 causal paths,且 claim invariant 有独立真实后端通过证据,因此这是独立的主干/环境 hold,不是这份 PR 的回归。premerge gate 仍为 failed,未删除检查、提高预算、修改活跃状态或伪装通过。按当前 wait_for_ci=false 未读取/等待 CI。NoKV integration 与持续多主机吞吐未运行,不能凭这些测试宣称已通过。
我的整体评价
APPROVE,限此 exact head 的完整 PR 判断。目标增量明确、生产机制有界、权威和失败监督继续共用原 owner,测试保护真实可复现回归而非新增抽象。未来重构检查已落实为私有完整 attempt,未添加通用 retry 框架或兼容分叉。维护者合并与独立 premerge hold 仍需单独处理;本评审没有合并授权,也未升级本机或关闭父级产品验收。
English verdict: APPROVE - 7ddeddb481924621265a424bb7f0fa02ad525f2f. Bounded canonical claim revalidation preserves receipt identity and authority; File 326, SQLite 338, real PostgreSQL 322 and seven CLI tests pass. Five expected base regressions disappear in the same seven-case File comparison. Nine premerge failures reproduce unchanged on immutable main; the separate merge hold remains. CI was not consulted.
Goal And Delivered Outcome
Two canonical claim commands for independent Todos can read the same provider head. Previously one succeeded and the other returned a revision conflict even though its target and write scopes were still eligible.
The TS claim owner now absorbs up to two conclusive provider-revision CAS conflicts. Every attempt uses the original operation/lease identity, rereads the receipt and complete authority, and revalidates source registration, ownership, acceptance and lease scopes. Same-Todo or overlapping-scope losers receive the current semantic rejection. Explicit revisions/transfer grants remain pinned; ambiguous writes keep the existing receipt-recovery path.
This is a bounded canonical-writer adoption under the existing TypeScript migration/shared-authority contracts. Base:
main; independent of #5370.Scope And Continuation
Complete within this scope: automatic revalidation of unrelated CAS contention in canonical claims, with public CLI adoption and no new API or provider. The generic receipt helper remains recovery-only. Recommendations are still advisory, and local writer serialization remains unchanged. Sustained multi-host contention frequency and throughput are not established by these synthetic races.
Future-facing pass: the existing claim transaction is retained as a private attempt function rather than duplicating authorization or lease rules. Retry ownership stays in the typed claim command. A broader claim-next/reservation protocol is outside this fix.
Validation
Tested exact head:
7ddeddb481924621265a424bb7f0fa02ad525f2f, integrated with immutable main850268bffc6f7123e88f578d3743f8f6da5c5c73. The integration resolves only the two bilingual RFC conflicts and preserves both the claim-contention and scoped gate-action checkpoints.cqr_beabc7329dba57135c17matches the five-file final diff.No GitHub CI was consulted under the configured review policy. NoKV integration and sustained multi-host throughput were not run; this PR changes no provider implementation. Maintainer merge and resolution of the separate premerge environment hold remain required. No active Goal state was used for validation.
Frontend / Visual Evidence
UI impact: none. The existing canonical CLI claim path inherits this behavior; no frontend/Lark action contract changes.
Shared-authority RFC fixture impact
Existing native Todo/lease fixture schema is retained. Changed dimensions: claim retry admission, operation identity, write-scope exclusion and latest authority after CAS. The native/legacy provider suites preserve compatibility and receipt behavior. File, SQLite and PostgreSQL conformance arms were executed; promotion/three-arm rehearsal is not applicable because routing, promotion and projection schemas are unchanged.
Boundary Checklist